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[57] ABSTRACT 

A computer system arranges multiple monitors in logical 
space to form a contiguous and non-overlapping region by 
determining relative positions in logical space for the moni- 
tor spaces, comparing the relative positions of the monitor 
spaces, and positioning the monitor spaces in logical space 
based on a result of the comparing. The comparing and 
positioning may be performed upon initialization of the 
computer system, or automatically in response to a geometry 
change (e.g., add/remove/move monitor, change monitor 
characteristics), or both. Following a monitor geometry 
change, windows or other graphic objects appearing in the 
monitor spaces may be positioned as needed to maintain a 
robust virtual desktop environment. 
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LOGICAL MONITOR CONFIGURATION IN SUMMARY 

A MULTIPLE MONITOR ENVIRONMENT , n Qne iSJ ^ of the a compm er system 

BACKGROUND arranges multiple monitors in logical space to form a con- 

This invention relates to configuring monitor screen dis- , ug»°«s ™° non-overlapping region by determining relative 

plays in a multiple monitor environment. " P 0 ^™ 5 in lo g Ical spMete me . mon,tor ^^panng 

A typical computer system as shown in FIG. 1 includes a * e re,ative P<*" l0as 0 ,he monitor spaces, and P°™ng 

l • .i • in4 « the monitor spaces in loeical space based on a result ol the 

computer 300 having a central processing unit 304, an lucUM llu !( ? *\ , , 

\ . , im * - • «„ r compannc. The companne and positioning are perforraed 

input/output unit 306 and memory 302 containing various F ; . P.. . / . & v . j# . 

H j u .u t _k „ upon mitia izalion of the computer system and/or automati- 

proerams used by the computer 300 such as an operating 10 . \ J , , 

v & ^r rt , z r r © iu j v n response t0 a geometry change (e.g., add/remove/ 

system 303 and one or more application programs 305. An c<m ' b ' . b \ ■ V u 

end-user of the computer system communicates with com- ™™ monitor > chao f a monitor characteristic such as a 

miter by means of various input devices (keyboard 320, resolution parameter). 

mouse 310) which transfer information to the computer via In one embodiment, the comparison of monitor spaces is 

input/output unit 306. The computer 300 replies to this input 15 accomplished by iteralively comparing the position ot each 

data, among other ways, by providing responsive output to monitor space against every other monitor space and 

the end-user, for example, by displaying appropriate text and determining, for example, whether any two monitor spaces 

images on the screen of a display monitor 330. overlap one another or whether gaps exist between the 

Operating systems often include a graphical user interface monitor spaces Based on this determination, monitor spaces 

TGUI") by which the operating system and any applications 20 may be moved inward in logical space to remove gaps 

t may be running (e.g , a word-processing program) may between monitor spaces, or they may be moved outward in 

communicate with an end-user. A commonly used GUI ^al space until no monitor space overlaps any other 

implementation employs a desktop metaphor in which the mooter space. Tins movement may occur in ar i iterative 

screen of the monitor is regarded as a virtual desktop. The b * mo ™S ° ne mon ^ r * * t ™'. ^ oreo * e ' £ 

desktop is an essentially two-dimensional working template a monitor spaces may be moved first outward m logical space 

area supporting various graphic objects, including one or until no monitor space overlaps any other monitor space, and 

more diplay regions (e g., window, dialog box pop-up then moved inward in ogtcal space to remove gaps between 

menu, pull -down menu, drop-down list, icon). As shown in monitor spaces and form a contiguous, non-overlapping 

FIG. 2, information is displayed on the desktop 21 within virlual desktop. 

display regions 23, which typically are rectangular in shape. 30 Certain types of overlaps between monitor spaces may be 

Each display region 23 may be dedicated to a specific recognized, for example, horizontal, vertical, large small, 

application or to the operating system under which the nearly vertical, nearly horizontal. Each ol these overlap 

applications are running. By manipulating a cursor 25 (such types may be treated differently so that overlaps are resolved 

as with standard point & click and drag & drop techniques), in an efficient and logical manner. 

an end-user can manage the display regions 23 as desired, 35 The comparison of monitor spaces may involve a com- 

for example, by creating new display regions or eliminating parison between the respective positions of two monitor 

old ones, or by resizing or repositioning the display regions spaces relative to a predetermined location, for example, the 

to fit the end-user's needs. The end-user may "activate" a center of the virtual desktop. In that case, one of the two 

particular display region and its associated application, for monitor spaces is moved based on a relationship between the 

example, by "clicking" the cursor 25 when it appears within 40 predetermined location and the position of the monitor space 

the desired region. to be moved. For example, the monitor space that has a 

In a computer system using a single monitor 330 as shown center point farther from the center of the virtual desktop 

in FIG. 1, a problem of screen clutter may occur when an may be moved outward in logical space, 

end-user has a large number of display regions open on the In another aspect, multiple monitor spaces may be 

monitor at the same time. Screen clutter tends to confuse the 45 arranged in logical space by (a) selecting one of the monitor 

end-user and reduce his or her efficiency. Moreover, end- spaces, and (b) comparing its position with another monitor 

users of certain applications (desktop publishing, CAD/ space, for example, to detect the presence of an overlap. 

CAM/CAE, videoconferencing, etc.) typically will want to Then, (c) one of the two monitor spaces is moved, for 

be able to view and use two large display regions (e.g., an example, outward in logical space, based on a result of the 

editing window and an output window) at substantially the 50 comparison in (b). Then in (d), the comparison in (b) and the 

same time, but often the most useful sizes of the two movement in (c) are repeated until the monitor space 

windows are too large to fit side-by-side on a single monitor. selected in (a) does not overlap any other monitor space. For 

To alleviate this problem, a computer system such as that each of the remaining monitor spaces, the operations of (a), 

shown in FIG. 3 having two monitors 330 and 332 has been (b), (c) and (d) arc repeated until no monitor space overlaps 

used Each monitor 330, 332 has a monitor space 41, 43 55 any other monitor space. In operation (c), the monitor spaces 

which is defined by the logical height and width of the that has a center point farther from a predetermined location, 

display In the multiple monitor system of FIG. 3, the for example, the center of the virtual desktop, may be the 

combination of the monitor spaces (two in the case shown— one that is moved outward in logical space, 

one monitor space 41 corresponding to monitor 330 and a Following operations (a)-(e), the monitor spaces may be 

second monitor space 43 corresponding to monitor 332) may 60 formed into a contiguous region (f) by selecting one of the 

be treated as a single, continuous display space— e.g., virtual monitor spaces (for example, the monitor space closest to 

desktop 45 as shown in FIG. 4. Through appropriate cursor the center of the virtual desktop) and (g) by designating it as 

manipulations, an end-user may move objects, such as belonging to a known group while designating the unchosen 

windows A, B, C, D and cursor 25, back and forth between monitor space or spaces as belonging to a unknown group, 

the two monitor spaces 41 and 43 or may even position one 65 Then, in operation (h) a monitor space is selected from the 

of these objects (e.g., window C in FIG. 4) so that it spans unknown group based on a relationship between it and the 

the two monitor spaces. known group. In (i), the monitor space selected in (h) is 
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moved in logical space, for example, until it becomes 
contiguous with one of the members of the group of known 
contiguity. Following the move in (h), the moved monitor 
space is (i) designated as belonging to the known group. The 
operations in (h), (i) and (j) are repeated until the monitor 5 
spaces form a contiguous region. 

In reconfiguring the virtual desktop, the monitor spaces 
may be moved to a constrained position in logical space, for 
example, a position which enhances efficiency in an oper- 
ating system of the computer system. This position may be 10 
a boundary aligned at a predetermined number of units in 
logical space which allows faster drawing operations to be 
performed among different display regions. 

In another aspect, windows or other graphic objects 
appearing in the monitor spaces may be positioned as 15 
needed following a monitor geometry change to maintain a 
robust virtual desktop environment. In one embodiment, this 
is accomplished by recording a position for each of the 
monitor spaces that forms logical display space after a 
geometry change (e.g., add/remove/move monitor, change 20 
of monitor characteristic) has been sensed. The geometry 
change may be such that it changes the shape and/or 
orientation of the display space. The graphic object is then 
manipulated in response to the geometry change, for 
example, by repositioning it logical space to compensate for 25 
the change in shape and/or orientation of the display space. 
This movement may be such that it causes the graphic object 
to appear in the same location in a monitor space before and 
after the geometry change. Alternatively, to compensate for 
the removal of a monitor space, the movement may be such 30 
that it causes the graphic object to appear in a different - 
monitor space than it was in prior to the geometry change. 

Advantages of this invention may include one or more of 
the following. An end-user is provided with a robust virtual 35 
desktop environment which may be composed of two or 
more monitor spaces. At system start-up, the program code 
will automatically arrange the various monitors plugged into 
the system in logical space to form a non-overlapping, 
contiguous region. The program code aligns the monitors in 
logical space at certain positions that allow the graphics 
engine to operate in a more efficient manner. The resulting 
virtual desktop will provide the end -user with increased 
screen real estate while at the same time it will behave and 
respond essentially as if it were contained on a single ^ 
monitor. As a result, the end-user will find thai his interac- 
tion with the virtual desktop remains logical and predictable 
even when the desktop spans two or more monitor spaces. 

During run-time, an extra monitor may be added on the 
fly, or an existing monitor may be deactivated and, in 50 
response, the program code dynamically adapts the virtual 
desktop environment accordingly. The program code 
removes any gaps or overlaps created in the virtual desktop 
by the change in monitor configuration. This is done in an 
efficient manner that does not disconcert the end-user. Also 5S 
in response to a monitor configuration change, the program 
code dynamically repositions windows or other graphic 
objects as needed to avert end-user astonishment. This 
action includes repositioning windows and other graphic 
objects so that they remain visible to the end-user, and ^ 
continue to respond to the end-user in a predictable manner, 
following a change in monitor topology. 

Other advantages and features will become apparent from 
the following description, including the drawings and 
claims. 65 

The methods and mechanisms described here are not 
limited to any particular operating system or hardware 



,307 
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configuration, but rather they may find applicability in any 
computing or processing environment that uses multiple 
output devices. 

The techniques described here may be implemented in 
hardware or software, or a combination of the two. 
Preferably, the techniques are implemented in computer 
programs executing on programmable computers that each 
include a processor, a storage medium readable by the 
processor (including volatile and non-volatile memory and/ 
or storage elements), at least one input device, and two or 
more output devices. Program code is applied to data entered 
using the input device to perform the functions described 
and to generate output information. The output information 
is applied to one or more output devices. 

Each program is preferably implemented in a high level 
procedural or object oriented programming language to 
communicate with a computer system. However, the pro- 
grams can be implemented in assembly or machine 
language, if desired. In any case, the language may be a 
compiled or interpreted language. 

Each such computer program is preferably stored on a 
storage medium or device (e.g., CD-ROM, hard disk or 
magnetic diskette) that is readable by a general or special 
purpose programmable computer for configuring and oper- 
ating the computer when the storage medium or device is 
read by the computer to perform the procedures described in 
this document. The system may also be considered to be 
implemented as a computer-readable storage medium, con- 
figured with a computer program, where the storage medium 
so configured causes a computer to operate in a specific and 
predefined manner. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a computer system having a 
single display monitor. 

FIG. 2 is a screen diagram showing display regions in a 
graphical user interface as used in the computer system of 
FIG. 1. 

FIG. 3 is a block diagram of a computer system having 
multiple display monitors. 

FIG. 4 is a screen diagram showing display regions in a 
graphical user interface as used in the computer system of 
FIG. 3. 

FIG. 5 is a single monitor display architecture block 
diagram for the computer of FIG. 1. 

FIG. 6 is a multiple monitor display architecture block 
diagram for the computer of FIG. 3. 

FIGS. 7(a) and 1(b) are monitor space diagrams showing 
examples of an overlapping, non-contiguous desktop and a 
non-overlapping, contiguous desktop, respectively, using 
three monitors. 

FIGS. S(a)S(g) are monitor space diagrams showing 
examples of monitor space geometry changes and changes 
in the number of monitors. 

FIG. 9(a) is a screen snapshot of a 1024x768 pixel 
desktop which includes a window that allows an end-user to 
change desktop area. 

FIG. 9(b) is a screen snapshot of an 800x600 pixel 
desktop for the same scene shown in FIG. 9(a). 

FIGS. 10(a) and 10(6) are screen shots showing a window 
that allows an end -user to change the logical positions of 
monitor spaces. 

FIGS. ll(a)-ll(c) are screen diagrams showing succes- 
sive representations of three monitors as they are reposi- 
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tioned in logical space to form a contiguous, non- and the monitor in response to calls made to functions of the 

overlapping region. operating system in general and to functions of GDI in 

FIG. 12(a) is a flowchart for removing overlaps between particular, 

monitor spaces. Communication between the GDI and the device driver is 

FIG. 12(6) is a flowchart for removing gaps between 5 facilitated by a device driver interface 38 ("DDF')- DDI 38 

monitor spaces. is a set of functions provided by the device driver for access 

FIGS. 13(a)-13(0 are monitor space diagrams showing b ? GDI 34 ' Information is passed between GDI and the 

different types of overlaps between two monitor spaces. device dnver mrou e n lD P m and 0Ut P m Peelers of the 

ct<-c *At \ *At^ ■> i * . . DDI functions. A GDI call to the "DrvEnableDriverf V' 

FIGS. 14(a>-14tf) ^ monitor space diagrams showing 10 iniiMzes the device driver and back tQ ^, 

different examples of contiguous, non-overlappmg regions. a fuQcUon ^ of(|riwMpporled DDI functions. GDI itself 

FIGS. I5(a)-l$(d) are dual monitor diagrams showing an handles any operations not represented in the function list 

example of repositioning windows in response to a change received. For example, if the device driver lacks an optional 

in monitor space geometry. function "DrvUneTo( )" for drawing a single solid cosmetic 

FIGS. 16(a)-l 6(c) are dual monitor diagrams showing an 15 line, GDI handles drawing the line without catling 

example of repositioning a straddling window in response to DrvLineTo( ). Another function "DrvDisableDriver( )" is 

a change in monitor space geometry. called by GDI when the device driver is to be unloaded. 

FIGS. \l(ay-\l{c) are dual monitor diagrams showing an Most of the functions are exposed to GDI through an array 

example of repositioning an orphaned window in response 01 pointers residing in a pointer table, 

to a change in monitor space geometry. 20 GDI maintains important internal data structures and 

provides the device driver with access to public fields (i.e., 

DETAILED DESCRIPTION externally-relevant fields) of these structures by passing the 

Operating in a multiple monitor environment creates P ublic ficlds ™ GDI/DDI software objects to the device 

several complexities and problems that are not present in a „ drivcr - GDI/DDI software objects are intermediate 

single monitor environment. In particular, the manner in dala structures providing an interface between GDI data 

which the virtual desktop and any graphic objects thereon structures and a device driver needing access to information 

should be handled and displayed in a GUI in response to thc GDI data structures. Atypical GDI/DDI software 

end-user input (or application program requirements) varies ob J ecl provides information such as colors of a palette 

considerably between the single monitor and multiple moni- 30 associated with the screen or definitions of brush objects for 

tor environments. If single monitor solutions were applied in graphic functions that output lines, text, or fills. The device 

a multiple monitor environment, application programs dnver can pass a pointer to a GDI/DDI software object back 

would appear to the end-user to behave incorrectly or 10 9 DI t0 que ^ for inform ation or to request execution of 

strangely and the end-user frequently would be confused and various operations. 

frustrated by his interaction with the GUI. Moreover, if the 3S In response to application program originated function 

multiple monitor spaces were not properly arranged in calls routed through GDI, the device driver ensures that the 

logical space relative to one another, the end-user would be video display adapter produces the required output. That is, 

confused by any resulting gaps, overlaps, and/or perceived in response to a request from an application, if GDI deter- 

discontinuities in the virtual desktop. To appreciate the mines that a function relating to the request is supported by 

differences between a single monitor and multiple monitor ^ the device driver, GDI calls the function. It is the respon- 

environment with respect to the manner in which monitor sibility of the device driver to execute the function properly 

spaces and graphic objects should be managed by a GUI, a and return control to GDI upon completion of processing 

basic understanding of their respective display architectures instructions associated with the function, 

is helpful. Some DDI functions are necessary for communication 

One operating system that uses a GUI is the Microsoft® 45 between GDI and DDI, while others arc optional. Necessary 

Windows®95 operating system, which is described in the DDI functions include "DrvGetModes( )" for listing video 

Microsoft® Development Library (July 1996), incorporated modes supported by the adapter and "DrvAssertMode( )" for 

herein by reference. FIG. 5 is an abstract representation of resetting thc video mode. Depending on how a device driver 

a display architecture that may be used in Windows®95 for is implemented, other functions may or may not always be 

the single monitor computer system of FIG. 1. As shown in 50 necessary. For example, a display driver typically is not 

FIG. 5, an end-user uses a presentation shell 31 (e.g. a GUI) required to handle fonts unless the device adapter involved 

to communicate with thc operating system and one or more has one or more resident fonts, which are fonts defined by 

application programs 32. An application running on the the adapter, not by the operating system. If the adapter has 

computer system may display information in one or more of a resident font, the device driver supplies information to 

the display regions through a graphical device interface 55 GDI about the font. 

subsystem 34 ("GDI") provided by the operating system. i n the typical situation, the device driver updates the 

GDI serves as a link between the application program and a status of the video display adapter in response to calls to its 

graphics device, such as a video display adapter 36 (e.g., a DDI by changing the contents of memory and registers used 

plug-in card) included with the computer to provide graphics by the adapter. The memory used by the adapter is referred 

output signals to the computer monitor 37. 60 to as "screen memory" or the "frame buffer." What appears 

GDI lies logically between the application program 32 on the monitor's screen is controlled directly by the adapter 

and a graphics device driver 35, which is a computer and corresponds to the contents of the screen memory and 

program designed to control a particular graphics hardware the registers. The device driver also typically performs 

device such as the video display adapter. The device driver additional functions such as monochrome-to-color conver- 

is not technically part of the operating system. Rather, the 65 sion of bitmaps, drawing of repetitive patterns in screen 

driver is a software module supplementing the operating memory, and moving of an image from one portion of screen 

system for updating the status of the video display adapter memory to another (referred to as a "bit block transfer" or 



10/03/2002, EAST Version: 1.03.0002 



5,923,307 

7 8 

"BitBlt"). Often, the operating system cannot perform these objects such as display windows, selection menus appearing 

additional functions as quickly because, unlike the device in the display windows, graphical icons, and the like. For 

driver, the operating system is not configured to take advan- example, an application program can call a USER function 

tage of the video display adapter's particular characteristics to remove a display window associated with the application 

and capabilities. 5 program. USER also controls other resources such as a 

„ " . - i- sound driver, a timer, and communications ports. In 

When an application or an operating system function . from a mousCj a k board> or olher 

needs to use a graphics hardware device such as the video . I dcvicc ^ b US£R {Q aQ application program . 
display adapter, the application calls GDI s "CreateDC( ) ]q ^ of mc Windows(g) operating syslem products 
function, via GDI's application programming interface . g ., windows® 95), USER is able to interact directly with 
(-API"), with a data string specifying the name of the device W ^ ^ {q ^ US£R e 
(e.g., "Display") In response a data structure known as a ^ ^ driver tQ c cursof dircctl L ^ 
"device context- is created for the device. The device dcvicc ^ m ^ direcd availab , c ccrtain h naions 
context reflect the current state of many attributes deter- fc iq d[s l ^ a mousc intcr (cursor) ^ csc func . 
mining how GDI functions work on the device. Among the ^ mcludc ^ C hcckCursor( )" for drawing the cursor if 
attributes specified in the device context are a ^xt font (i.e., 15 ^ ^ ^ ^ «lnquireCursor( )" for retrieving 
typeface), a text color, the background color behind the text, inhrm ^ on abcmi thc curs0T> « M oveCursor( )" for moving 
and intercharacter spacing, lhc cufsor tQ a spccificd posilion OQ thc and 
When CreateDC is called, GDI returns a handle ("hDC"), »SetCursor( )" for setting the cursor's shape. In other 
which is a pointer to the device context and which is used Windows® operating system products (e.g., Windows® 
later by the application to interact with thc device context by USER docs not communicate directly with the adapt- 
passing the handle to other GDI APIs. GDI also identifies a cr > s d cv ice driver but rather communicates with NT's 
graphics device driver for the device specified by the data equivalent of GDI (referred to as "GRE" for "graphics 
string (e.g., "Display"). GDI then calls operating system engine"), which in turn communicates with the device 
functions to load the specified device driver. Once the device driver. 

driver is loaded, GDI is able to communicate with the device when thc Wmdows ® 95 operating system first starts (at 

through DDI functions. Viz the device driver, GDI is able to "boot-time"), USER calls the InquireCursor( ) function to 

perform actions such as initializing the device and drawing rctr i eve information about the cursor. USER then sets a 

graphics on the screen of the monitor driven by the device. system limer {0 call the checkCursor( ) function on each 

Multiple hDCs may exist for a single device, so that multiple ^ timcf intcrmpt (; c ^ at predetermined intervals) and starts a 

application programs can cause graphics to be drawn on a mouse-related device driver. As a result, whenever it is 

single device. GDI handles the synchronization between the movcd by thc ^0^^ tne mouse generates an event (e.g., 

"DCs- a hardware-based, asynchronous interrupt) causing ihe oper- 

GDI has several hundred functions making up several a ting system to call MoveCUrsor( ) to re-display the cursor 
broad groups. One group includes CreateDC( ) and other 35 image at the screen location designated by the end -user, 
functions providing the operating syslem and application USER and application programs subsequently set the shape 
programs with the ability to control the existence of device 0 f the cursor using SetCursor( ). In this example, because 
contexts. Another group includes functions providing device USER calls MoveCursor( ) at the occurrence of each mouse 
context information such as the dimensions of a currently- move event, MoveCursor( ) sets a flag with a non- 
selected font. Functions relating to displaying text or draw- ^ interrupt able instruction (e.g., "bts") to prevent the 
ing graphics such as lines, filled areas, and bit-mapped MoveCursor( ) function from being called again before 
images are included in another group. Still another group completing processing of a current call. Once the flag is set, 
provides functions for setting and determining the status of MoveCursor( ) determines a new position (i.e., the x and y 
device context attributes relating to details such as the color coordinates) and draws the cursor in the new posilion. When 
and justification of text. Functions of yet another group 45 finished, MoveCursor( ) clears, the flag with another non- 
provide access to GDI objects, which are constructs such as interruptable instruction. Meanwhile, the CheckCursor( ) 
logical pens and brushes, and which allow the setting of function is called at each timer interrupt to determine 
widths and styles of lines and other graphics drawn in the whether the cursor should be redrawn and whether drawing 
display windows on the screen. is enabled. If so, the function redraws the cursor. 

The display windows appearing on the screen are con- 50 Windows® NT does not use interrupts for performing 

lained within a logical space corresponding to the desktop. cursor display and management functions but rather uses 

The screen of the monitor may show only a portion of the asynchronous procedure calls ("APCs") — an alternative 

desktop at any given time. The operating system allows mechanism for handling events. An APC is a function that 

applications running on the computer to specify desktop executes asynchronously in the context of a particular 

object characteristics such as colors, font sizes, output 55 thread. Whenever the mouse is moved or otherwise manipu- 

resolutions and the like without regard for the specific lated by the end-user, an APC is queued for a thread 

limitations of a particular video display adapter or monitor. dedicated to input handling. When this thread next runs, it 

GDI converts the application's specified characteristics to executes the functions specified by thc APCs in its queue, 

conform to the adapter's and monitor's limitations. For The dedicated input thread runs concurrently with any active 

example, the application may specify a yellow color, but the ^ applications and performs essentially the same functions for 

adapter and monitor combination may be capable of dis- managing the cursor as described above with respect to the 

playing gray scales only. If so, GDI converts the yellow interrupt-based event handling mechanism, 

color to a gray scale. Once a device context has been initialized, USER queries 

When the operating system is started the video display the device for several of its characteristics and capabilities 

adapter is initialized by another operating system subsystem 65 so as to properly maintain the desktop. Initializing the device 

"USER" 33. USER provides functions relating to the GUI, context provides USER with information about icons, key 

including functions to create, move, size, and remove screen and mouse cursors, and bitmap resources for defining the 
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appearance of other screen objects such as graphical buttons intentions and which does not surprise, confuse or frustrate 

controlling the presence of a display window. After it has the end-user in interacting with the GUI. A robust multiple 

been initialized by USER, the device context remains fairly monitor GUI is described in commonly- assigned U.S. Ser. 

stable for the duration of the Windows® session, i.e., until No. 08/786,969 filed Jan. 27, 1997, entitled "ROBUST 

the operating system is restarted for some reason. s DISPLAY MANAGEMENT IN A MULTIPLE MONITOR 

In Windows® 95 and in Windows® NT, USER supports ENVIRONMENT" which was filed concurrently with this 

reconfiguring the dimensions of the monitor space (i.e., the application and is incorporated by reference, 

logical width and height of the screen) during the Win- USER'S responsibilities further include providing the 

dows® session. The logical width and height are measured end-user with a continuous display space (e.g., virtual 

in picture elements ("pixels") organized in a raster grid. A 10 desktop) regardless of the number of monitors (one or more) 

pixel refers to the smallest unit of the screen addressable via from which the display space is composed. This task is 

the screen memory and is usually represented in the screen relatively straightforward in a single monitor environment 

memory by multiple bits representing the state of one or because a single monitor is, by definition, a continuous 

more characteristics (e.g., color) of the pixel. For example, display space. Performing this task in a multiple monitor 

the color of the pixel may be represented by 24 bits, i.e., a 15 environment poses several challenges that were not present 

pixel's color may have a "bit-depth" of 24. In the case of a in the single monitor environment. 

computer monitor employing cathode-ray tube ("CRT") Accordingly, in one embodiment, USER dynamically 
technology, a pixel corresponds to a phosphor dot or a set of manages the configuration of multiple monitors in logical 
phosphor dots configured to illuminate when struck by one space such that an end-user is presented with a continuous 
or more beams emanating from an electron gun. -, 0 display space that spans two or more monitors. This con- 
Changing the logical height and width of the screen " timious display space behaves and responds to the end- user 
during a Windows® session is accomplished by instructing essentially in the same manner as if a single monitor were 
the device driver to direct the video display adapter to being used. USER accomplishes this robust management 
re-initialize itself with the new height and width. Assuming through program code specifically designed for the multiple 
the adapter is capable of such a re-initialization, USER 25 monitor environment. The specialized program code (the 
subsequently queries the adapter for its capabilities and "reconfiguration code") logically can be divided into two 
updates its internal information about the adapter. USER broad categories: (1) program code that arranges the com- 
also updates the positions on the screen of any of the ponent monitor spaces such that they form a contiguous, 
desktop's display windows that are affected by the change. non-overlapping display space at boot-time, and whenever 
Typically, like the size of the screen, the size of a display 30 the display space undergoes a geometry change; and (2) 
window is measured in pixels. Thus, for example, if a screen program code that, following a display space geometry 
originally having a size (i.e., resolution) of 1024 (width) by change, manages (e.g., relocates or resizes) windows or 
768 (height) pixels is changed to a resolution of 640 by 480 other display regions such that they are displayed and 
pixels, one or more display windows that were originally behave in a logical manner that averts end-user astonish- 
completely visible may lie partially or completely offscreen 35 ment. 

after the change. Also, as a result of the change in resolution, When the operating system boots in a multiple monitor 

a window originally sized to cover a considerable portion of environment, the component monitors are initialized at 

the desktop may no longer fit on the screen. USER reposi- indeterminate locations in logical space. Most likely, the 

lions any such windows, first by attempting to move those relative positions of the monitors in logical space will be 

windows horizontally or vertically or both, and then, if 40 such that overlaps and/or gaps between monitors will exist, 

unsuccessful, by resizing the windows to fit within the As shown in FIG. 7(a), for example, a three monitor system 

available desktop space. might initialize itself such that an overlap 53 exists between 

FIG, 6 illastrates a multiple monitor display architecture monitor space 1 and monitor space 2 and gaps 51 and 52 

that may be used which includes two device drivers 35, 203 exist between monitor space 3 and monitor spaces 1 and 2, 

and two monitors 37, 207. The multiple monitor architecture 45 respectively. Note we are referring here to the logical 

is similar to the single monitor display architecture except monitor space. The monitors themselves would of course be 

that it also includes a Forking Display Driver 201— a piece physically separate, incapable of overlap. An end-user work- 

of software code that may be dynamically inserted or ing with an aggregate display space (a virtual desktop 50 

removed when a second monitor is installed or removed composed of the union of monitor spaces 1, 2 and 3 as they 

accordingly. The forking display driver effectively splits the 50 are arranged in FIG. 1(a)) quickly would become frustrated 

graphics stream from the GDI into a number of parts equal and confused by interacting with the GUI while seeing a 

to the number of monitors being used (e.g., two parts for two different physical geometry. For example, if the end-user 

monitors) and thus distributes the virtual desktop across moved a graphic object (e.g., cursor image or window) into 

multiple monitors. Details on the forking driver may be overlap region 53, logically a dual image of the object 

found in commonly-assigned U.S. Ser. No. 08/786,971 filed 55 should appear simultaneously on monitors 1 and 2 because 

Jan. 24, 1997, entitled "ALLOCATING DISPLAY the object is present in both monitor spaces. No such dual 

INFORMATION," which was filed concurrently with this image is generated in practice, however, because to do so 

application and is incorporated by reference. would pose substantial technical difficulties and would pro- 

As noted above, the USER code is responsible for, among vide little, if any, corresponding benefit to the end-user. To 

other things, the manner in which the desktop and various 60 ^ contrary, a dual image display more likely would confuse 

graphic objects (e.g., windows, menus, dialog boxes, the th e end -user. 

cursor and the like) are displayed to the end-user. When the On the other hand if the end-user moved an object from 

end-user enters input via the mouse or keyboard that is monitor space 1 to the right into null region 54, the object 

intended to affect the display (e.g., cursor movement, win- would become invisible to the end-user (i.e., displayed on 

dow repositioning or resizing), it is USER'S job to respond 65 neither monitor) and potentially irretrievable, 

to that input by changing the display in a robust manner — Accordingly, USER prevents these problems by automati- 

i.e., in a manner that accurately reflects the end-user's cally arranging the monitor spaces relative to each other in 
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logical space to form a contiguous, non-overlapping region monitor spaces is moved outward in logical space until the 
as shown in FIG. 1(b). As a result, the end-user is presented detected overlap is eliminated. This process of detecting and 
with a continuous virtual desktop 50 that is devoid of resolving overlaps is repeated until no two monitor spaces 
overlaps and gaps, and which behaves in a robust manner — occupy the same logical space as shown in FIG. 11(6). Once 
i.e., essentially in the same manner as if the virtual desktop 5 the monitor spaces have been spread out and no more 
50 was within a single monitor space. Moreover, requiring overlaps remain, the reconfiguration code then packs them 
the virtual desktop to be contiguous and non -overlapping back in until they form a contiguous region as shown in FIG. 
allows other sections of the display architecture program U(c). The process of FIGS. 11 (fl)-U(c) is described in more 
code to opera le faster and more efficiently while in multiple detail with reference to the flowcharts of FIGS. 12(a) and 
monitor mode. For example, the USER program code that is to 12(b). By combining the two processes represented in FIGS, 
responsible for ensuring that the cursor image display 12(a) and 12(6), USER can take an arbitrarily positioned set 
always remains visible on exactly one monitor in a multiple of monitor spaces and reorganize them to form a non- 
monitor environment can perform its calculation more overlapping, contiguous virtual desktop, 
quickly as a result of the simplified geometry that arises piG. 12(a) is a flowchart of the steps taken by the 
from the non-overlap and contiguity requirements. The 15 reconfiguration code to remove overlaps between monitor 
forking display driver code also is enabled to run more spaces. Every monitor space is compared against every other 
efficiently by imposing these requirements on the virtual monitor space, and appropriate repositioning of monitor 
desktop. spaces is performed until no two monitor spaces overlap 

In addition to boot-time, USER dynamically arranges the each other. A portion of the program instructions used by the 

monitor spaces in response to certain run-time conditions — 20 reconfiguration code to remove overlaps is attached as 

namely, whenever the aggregate display space undergoes a Appendix A, and is incorporated by reference, 

"geometry change/' which is a change in the size or shape The first s t e p 156 is to pick a reference monitor space, 

or orientation of the aggregate display space. A geometry which at the start of the overlap removal process is chosen 

change generally falls into one of the seven situations shown arbitrarily. At step 158, the reference monitor space is then 

in FIGS. 8(a) through 8(g). 25 iteratively compared with every other monitor space looking 

In FIGS. 8(a) and 8(6), a geometry change occurs when for an overlap. If at step 160, it is determined that the 

an end-user turns on or otherwise activates an additional reference monitor space does not overlap any other monitor 

monitor beyond the monitor (or monitors) already present in space, the reconfiguration code determines at step 162 

the configuration. Just as with the initialization of monitors whether all of the monitor spaces have been so tested. If not, 

at boot-time, a monitor added during run time will initialize 30 the process returns to step 156 to pick another reference 

such that the origin of its monitor space is at an indetermi- monitor space, which in turn will be compared against every 

nate location in logical space. Consequendy, a newly added other monitor space to check for overlaps, 

monitor space could overlap with an existing monitor space The first instance in which an overlap between the refer- 

(FIG. 8(a)) or could be positioned such that a gap exists ence monitor space and another monitor space is detected at 

between the added monitor space and the preexisting moni- step 160, the reconfiguration code proceeds to determine the 

tor space(s) (FIG. 8(6)). In either case, the reconfiguration "type" of overlap that has been encountered. FIGS. 13(a) 

code will automatically restore the virtual desktop to a -13(/) show nine types of overlaps recognized by the 

contiguous, non-overlapping region. reconfiguration code. 

Similarly, a geometry change occurs whenever an existing ^ At steps 164 and 168, it is determined whether the 

monitor space is turned off or otherwise deactivated. As detected overlap is "horizontal" in nature (FIG. 13(a)) or 

shown in FIG, 8(c), the removal of monitor space 2 from the "vertical" in nature (FIG. 13(6)) or neither of the two. A 

aggregate display space creates a gap between monitor horizontal overlap exists if the upper and lower boundaries 

spaces 1 and 3, a condition that will be corrected by the of one of the monitor spaces fall on or within the vertical 

reconfiguration code by moving monitor spaces 1 and 3 45 range defined by the upper and lower boundaries of the other 

together in logical space such that they have adjacent monitor space. Similarly, a vertical overlap exists if the right 

borders. and left boundaries of one of the monitor spaces fall on or 

Geometry changes also may occur when certain charac- within the horizontal range defined by the left and right 

teristics of a monitor are changed. For example, an end-user boundaries of the other monitor space. If the overlap is 

may change the size of a monitor space as desired (using a 50 determined to be horizontal then the direction of separation 

special purpose GUI window such as shown in FIGS. 9(a) is set to be horizontal in step 166. If the overlap is deter- 

and 9(6)) so that it becomes larger (e.g., 1024x768 pixels as mined to be vertical then the direction of separation is set to 

shown in FIG. 9(a)), thereby causing it to overlap another be vertical in step 170. 

monitor space (FIG. 8(d)), or smaller (e.g., 800x600 pixels Steps 164 and 168 represent a quick check that is per- 

as shown in FIG. 9(6)), thereby causing a gap between the 5S formed by the reconfiguration code to identify whether the 

monitor spaces (FIG. 8(e)). In either case, the reconfigura- overlap is one of the two most common overlap cases, 

lion code dynamically restores the aggregate desktop to a namely the horizontal overlap of FIG. 13(a) or the vertical 

contiguous, non-overlapping state using the process repre- overlap of FIG. 13(6). Although this check is represented as 

sented by FIGS. ll(a)-U(c). two separate steps in FIG. 12(a), in fact the reconfiguration 

FIGS ll(a)-ll(c) illustrate the basic concept employed 60 code is able to determine, in a very short time, the presence 

by the reconfiguration code to enforce a contiguous, non- or absence of either condition based on the value returned by 

overlapping desktop. In FIG. 11(a), monitor spaces 1,2 and the function INTERSECTION_AXIS(a, b) (defined m 

3 have been initialized at boot-time in indeterminate states Appendix A), where a is one of the monitor spaces under 

such that their respective monitor spaces overlap one consideration and b is the intersection of the two overlap- 

anolher. The reconfiguration code's first step in eliminating 65 P^g monitor spaces. 

overlaps is to detect the presence of an overlap between any If INTERSECTlON_AXIS( ) returns a value of 0, the 

two monitor spaces. If an overlap is found, one of the overlap is vertical, and a return value of 1 means the overlap 



10/03/2002, EAST Version: 1.03.0002 



5,9: 

13 

is horizontal. If INTERSECTION_^AXIS( ) returns any 
value other than Oorl.it means that the type of overlap is 
"unknown" — i.e., it is neither horizontal nor vertical, as 
defined above. An unknown overlap is more difficult to 
resolve and typically falls into one of the following types: 
FIG. 13(c) in which the monitor spaces are diagonal to one 
another, FIG. 13(W) in which one monitor space is contained 
in the other monitor space; or FIG. 13(e) in which the 
monitor spaces cross each other. 

If the overlap satisfies the requirements neither of step 
164 nor step 168, the reconfiguration code proceeds to step 
172 to determine whether the overlap is "large" or ''small.'* 
A large overlap exists where one monitor space contains the 
center of the other monitor space as shown in FIG. 13(/). 
Otherwise, the overlap is regarded as small, for example, as 
shown in FIG. 13(g). If the detected overlap is found to be 
small, the direction of separation is set in step 174 to be in 
the direction (horizontal or vertical) of the smaller overlap 
distance. In FIG. 13(g), for example, the horizontal overlap 
distance 84 is smaller than the vertical overlap distance 86. 
Accordingly, for the overlap of FIG. 13(g), the direction of 
separation would be set to horizontal 

If, however, the detected overlap is found to be large, the 
reconfiguration code proceeds to step 176 to determine 
whether the monitor spaces under consideration are closer to 
being vertically aligned ("nearly vertical") or horizontally 
aligned ("nearly horizontal"). As shown in FIG. 13(A), a 
nearly vertical alignment exists if the vertical distance 88 
between the centers of the two monitor spaces is greater than 
the horizontal distance 90 between the centers. A nearly 
horizontal alignment exists if the horizontal distance 94 
between the centers of the two monitor spaces is greater than 
the vertical distance 92 between the centers, as shown in 
FIG. 13(i). If at step 176 the detected overlap is determined 
to be nearly horizontal then the separation direction is set to 
be horizontal at step 180, If, on the other hand, the detected 
overlap is determined to be nearly vertical, the separation 
direction is set to be vertical at step 178. 

Once the direction of separation has been set 
appropriately, the reconfiguration code determines at step 
182 which of the two monitor spaces under consideration 
will be moved to eliminate the overlap. The monitor space 
that will be moved is the one whose center is farthest from 
the center of the virtual desktop. At step 183, the monitor 
space identified in step 182 is moved away from the center 
of the virtual desktop in the direction set in one of steps 166, 
170, 174, 178 and 180. 

Several benefits arise as a result of the particular deci- 
sional criteria used in step 182 (move monitor space farthest 
from desktop's center) and step 183 (move monitor space 
outward). For instance, always moving monitor spaces out- 
ward to eliminate overlaps lessens the likelihood that that 
monitor will be moved into a position that overlaps another 
monitor space. If it does, that overlap will be resolved by 
moving one of the overlapping monitor spaces still farther 
out. This guarantees that a non-overlapping solution even- 
tually will be found. From the perspective of the end-user, 
the decisional criteria used in steps 182 and 183 use as much 
of the available logical space as needed and thus tend to 
minimize the number of monitor moves that are necessary to 
reach a non-overlapping solution. By keeping the convolu- 
tion of the monitor space layout to a minimum, the criteria 
used in steps 182 and 183 reduces the potential for end-user 
confusion. In contrast, overlap-removal criteria that allowed 
inward moves, or which otherwise tended to disfavor out- 
ward moves, necessarily would be more complex and thus 
would require a greater number of moves to reach a non- 
overlapping solution. 

After the overlap between the present two monitor spaces 
is eliminated in step 183, the reconfiguration code returns to 
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step 156 to continue its search for overlaps. This lime around 
the reconfiguration code selects as the reference monitor 
space in step 156 the same monitor space that was just 
moved in step 183. This process continues until it is deter- 
s mined at steps 160 and 162 that no two monitor spaces 
overlap. 

Once the various monitor spaces have been spread out 
such that no two overlap, the reconfiguration code pulls the 
monitor spaces back together so that they form a contiguous 
region, which is defined as a region in which each monitor 

io space "touches" any other monitor space in the group. A 
monitor space touches another monitor space if it has one 
edge that is at least partially coincident with an edge of the 
other monitor. Accordingly, each of FIGS. 14(o)-14(</) is an 
example of a contiguous desktop because each monitor 
space shares at least a portion of one of its edges with 
another monitor space within its group. 

FIG. 12(6) is a flowchart of the steps taken by the 
reconfiguration code to pull monitor spaces together to form 
a contiguous desktop. The first step 184 is to identify a 
monitor space that should serve as the starting point for the 

20 process. The particular monitor space identified in step 184 
is the monitor space that is closest to the center of the virtual 
desktop. The position of the starting monitor space will not 
change during the process of creating a contiguous desktop. 
Rather, the other monitor spaces will be moved relative to 

25 the starting monitor space as needed. This has the effect of 
closing gaps between monitor spaces by pulling the monitor 
spaces inward towards the starting monitor space, which by 
definition is at or near the center of the desktop. As a result 
of this inward motion, the monitor spaces are less likely to 
be pulled apart (which would otherwise cause new gaps to 
appear). This in turn reduces the potential for end- user 
confusion as convolution of the monitor space layout is kept 
to a minimum. 

Once the starting monitor space has been identified, it is 
added (logically speaking) to a group of "known contiguity" 

35 at step 186. At this point, all of the other monitor spaces are 
regarded as belonging to a group of "unknown contiguity." 
At step 188, a monitor space is chosen from the unknown 
contiguity group. The particular monitor space chosen is the 
one that is closest to any one of the monitor spaces belong- 

40 ing to the known contiguity group, which at this point has 
just one member — the starting monitor space identified in 
step 184. 

Before any monitor space is moved, however, the recon- 
figuration code checks at step 190 to see if moving the 

45 selected monitor space to a position where it would touch 
one of the members in the known contiguity group would at 
the same time cause it to overlap another monitor space 
belonging to the unknown contiguity group. If such an 
overlap would result, the selected monitor space is ignored 

50 for the time being and a different monitor space is selected 
from the unknown contiguity group. This process continues 
until a suitable monitor space is identified in the. unknown 
contiguity group. 

At this point in the desktop reconfiguration code, all 

S5 overlaps previously have been eliminated as described 
above in connection with the flowchart of FIG. 12(g). Step 
190 ensures that no new overlaps are created during the 
process of removing gaps. If monitor space moves were 
allowed during gap elimination such that new overlaps could 
be created, it potentially could undo the previous overlap 

60 elimination, thus preventing a contiguous, non-overlapping 
solution from being achieved. 

At step 192 the monitor space selected from the unknown 
contiguity group is moved so that it touches at least one of 
the monitor spaces in the known contiguity group. Horizon - 

65 tal or vertical movement is favored over diagonal movement 
because it produces good results especially in closing gaps 
caused by changing the monitor space size (e.g., FIG. 8(e)). 
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At step 194, the monitor space that was moved in step 192 
to touch one of the members in the known contiguity group 
is removed from the unknown contiguity group and added to 
the known contiguity group. At step 196, the reconfiguration 
code checks to see if any monitor spaces remain in the 
unknown contiguity group. If unknown contiguity group 
members remain, the reconfiguration code repeats steps 
184-196 until a contiguous virtual desktop is achieved. If 
none remain, it means that the virtual desktop has been 
formed into a contiguous region. 

At step 197, the reconfiguration code forms the virtual 
desktop from the monitors in the known contiguity group, 
which at this point includes all of the available monitors. The 
virtual desktop is formed by finding the union of the various 
monitors, which by definition is the smallest bounding 
rectangle that encompasses all of the monitors. The monitors 
are then repositioned as a group such that the upper left 
corner of the "primary monitor" is at 0,0 in logical space. 
The primary monitor was arbitrarily chosen by the operating 
system at boot-time from among the various monitors that 
were plugged into the computer system. 

In performing the calculations necessary to carry out the 
processes represented by FIGS. 12(a) and 12(b), the USER 
reconfiguration code optimizes placement of the monitor 
spaces forming the non-overlapping, contiguous desktop to 
enhance the speed with which GDI can use brush objects 
(logical constructs for drawing on a display) to draw across 
multiple displays. More particularly, the reconfiguration 
code ensures that the positions of the monitor spaces (which 
are assumed to have a resolution that is a multiple of 8 in 
both the X and Y axes) are constrained in logical space to fall 
on 8-pixel boundaries. This positioning is accomplished by 
performing the overlap/gap removal calculations in 8-pixel 
space (i.e., by dividing the monitor space data sets by 8 
before the calculations and then multiplying them by 8 after 
the calculations are complete). The standard size of a GDI 
brush object is 8 pixels. To use a brush object, GDI must 
create a "realization*' of the object by mapping, in memory, 
the logical definition of the brush object into the color 
lookup table. The realization operation uses processor time 
and memory. Ordinarily, each window requires its own 
separate realization of a brush object. Aligning monitor 
spaces on 8-pixel boundaries, however, allows the same 
realization of a brush object to be used on each of the 
monitors that form the desktop, thereby saving memory and 
enhancing the speed of GDI drawing operations. 

As noted above, whenever geometry changes occur such 
as those in FIGS. 8(a)S(e) in which the aggregate display 
space becomes other than a contiguous, non-overlapping 
region, the USER reconfiguration code, which is continu- 
ously executing, automatically enforces the contiguity and 
non-overlap requirements. Other types of geometry changes 
may occur — such as those shown in FIGS. 8(f) and 8(g) — 
that do not cause the virtual desktop to become non- 
contiguous or overlapping. Nevertheless, the reconfiguration 
will automatically reconfigure the logical desktop, thereby 
ensuring that robust end-user interaction is maintained. 

FIGS. 8(f) and 8(g) represent geometry changes that are 
caused by repositioning one monitor space with respect to 
another, thus requiring a corresponding repositioning of the 
monitor. In FIG. 8(f), the monitor spaces have been reposi- 
tioned such that monitor space 2 sits on lop of monitor space 
1 and in FIG. 8(g), the positions of monitor spaces 1 and 2 
have been swapped. Typically, repositioning of monitor 
spaces is performed by an end-user (using a special purpose 
GUI window such as shown in FIGS. 10(a) and 10(b)) so 
that the relative positions of the logical monitor spaces will 
mimic the relative positions of the physical monitors. In 
other words, an end-user may lift one CRT display unit and 
physically place it on top of another CRT display unit. In the 



current state of technology, the operating system has no 
means for automatically sensing that a physical geometry 
change has occurred, however. Accordingly, following a 
physical geometry change, the end-user must manually 
inform the operating system that the monitors have been 
physically moved relative to one another so that the oper- 
ating system from that point onward will be able to present 
and/or manipulate the virtual desktop, and any graphic 
objects thereon, in a manner that accurately reflects the 
end-user's intentions. 

FIGS. I5(a)-I5(d) illustrate an example situation in 
which the USER reconfiguration code manages windows in 
response to a geometry change to ensure robust interaction 
with the end-user. In FIG. 15(a), a horizontally oriented 
virtual desktop 100 is composed of two monitor spaces 
(corresponding to monitors #1 and #2) arranged side -by- 
side. Three windows, A, B and C, and a cursor image 102 are 
present on the virtual desktop 100. 

Assume the end-user decides that a vertically oriented 
desktop is preferable so he physically moves monitor #2 
from its location next to monitor #1 and places it on top of 
monitor #1. At that point, the situation would appear as in 
FIG. 15(b). Although monitor #2 physically is on top of 
monitor #1 so that windows B and C physically appear 
above window A, USER will continue to treat the virtual 
desktop and its windows as if the desktop 100 is horizontally 
oriented because USER is unaware that the physical monitor 
geometry has changed and thus has not yet reoriented the 
desktop. 

Although USER and any applications that may be running 
will not experience any problems, the state of affairs shown 
in FIG, 15(6) tends to confuse end-users. For example, 
suppose in FIG. 15(6) the end-user wanted to move the 
cursor image 102 so that it moves from monitor #2 to 
monitor #1. The end-user's natural tendency to accomplish 
this result would be to move the mouse toward him, expect- 
ing the cursor image 102 to translate downward towards and 
into monitor #1. However, because the virtual desktop 
remains horizontally oriented, the cursor image 102 would 
stop as soon as it reached the bottom of the screen in monitor 
#2 at position 106 (corresponding to position 104 of the 
logical cursor on the virtual desktop). 

To avoid such confusion, the end-user informs USER of 
the change in physical monitor position so that the recon- 
figuration code can perform a corresponding reconfiguration 
of the virtual desktop in logical space. To do so, the end-user 
interacts with the "Monitors" window shown in FIGS, 10(a) 
and 10(6). In particular, the end-user moves the icon 108 that 
represents monitor #2 from its position next to the icon 110 
representing monitor #1 (FIG. 10(a)) to a position on top of 
icon 110 (FIG. 10(6)). The reconfiguration code subse- 
quently uses the positional information provided by the 
end -user in reorienting the virtual desktop 100 to a vertical 
orientation as shown in FIG. 15(c). 

However, if USER were to change the orientation of the 
virtual desktop in the manner shown in FIG. 15(c) while 
leaving windows B and C and cursor image 102 at their 
same respective positions in logical space, the end-user 
would again become confused. As shown in FIG. 15(c). 
reorientation of the desktop 100 caused it to no longer 
contain windows B and C. Consequently, the cursor image 
and windows B and C would appear to the end -user to 
60 vanish the instant that USER reoriented the virtual desktop. 
To prevent such end-user contusion, USER repositions 
the cursor image and windows so that they are visible to the 
end -user as showo in FIG. 15(d). The cursor image 102 and 
windows B and C are moved in logical space to appear at 
65 their same respective positions in monitor #2, relative to the 
origin of monitor #2, as they did just prior to the geometry 
change. The USER reconfiguration code accomplishes this 
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by taking a "snapshot" of the virtual desktop layout (i.e., by 
saving in a data structure coordinate data that defines the 
relative positions of the monitor spaces) just prior to effect- 
ing a logical monitor geometry change. During the geometry 
change, USER uses the snapshot data structures to reposi- 
tion the windows so that they appear in the same place 
relative to the monitor on which they appeared just prior to 
the logical monitor geometry change. 

Another example situation in which the USER reconfigu- 
ration code dynamically repositions windows in response to 
a geometry change is shown in FIGS. 16(o)-16(c). In FIG. 
16(a), window A is positioned such that it straddles the 
boundary between the two monitor spaces corresponding to 
monitors #1 and #2. In FIG. 16(b), the end-user has physi- 
cally placed monitor #2 on top of monitor #1 such that the 
two portions of window A are no longer adjacent. When the 
end-user interacts with the monitor positioning window to 
tell USER about the geometry change, the USER recon figu- 
ration code automatically repositions window A so that it 
appears entirely within a single monitor space as shown in 
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Yet another example situation in which the USER recon- 
figuration code dynamically repositions windows in 
response to a geometry change is shown in FIGS. 17(a)-17 
(c). In this example, the virtual desktop is formed from the 
three monitor spaces corresponding to monitors #1, #2 and 
" #3, and has three windows — A, B and C — displayed therein. 
Assume that monitor #2 is deactivated subsequently either 
by equipment failure or by intentional actions of the end- 
user. This results in window B being "orphaned" (i.e., no 
longer appearing in an available monitor space) and thus 
10 rendered invisible to the end-user as shown in FIG. 11(b). In 
this situation, the end-user likely would become confused by 
the disappearance of window B and/or frustrated by the fact 
that he could not move window B back into view because its 
title bar was not visible for a dragging operation. In this case, 
after the end-user has informed USER of the geometry 
change, the reconfiguration code will move the orphaned 
window in logical space such that it appears entirely within 
the monitor space to which it is closest — monitor #1 in the 
case shown in FIG. 17(c). 
Accordingly, using the techniques described above, the 



FIG. 16(c), USER picks ihe monitor space based on the 20 USER reconfiguration code, at boot-time and in a dynamic 
relative amounts of window area that appeared in each 
monitor space prior to the geometry change. In the example 
shown, USER picked monitor #2 for display of window A 
because, as shown in FIG. 16(a), it contained a larger portion 
of window A than did monitor #1 just prior to the geometry 
change. 



fashion in response to a geometry change during run -time, 
ensures that the user is presented with a robust virtual 
desktop environment when operating in the multiple moni- 
tor domain. 

Other embodiments are within the scope of the following 
claims. 



APPENDIX A 



// lNTERSECnON_AXIS 0 

// This macro tells us how a particular set of overlapping rectangles 
// should be adjusted to remove the overlap. It is basically b condensed 
// version of a lookup table that docs the same job. The parameters for the 
// macro are two rectangles, where one is the intersection of the other with 
// a third (unspecified) rectangle. The macro compares the edges of the 
// rectangles to determine which sides of the intersection were "caused" by 
// the source rectangle. In the pre-condensed version of this macro, the 
// results of these comparisons (4 bits) would be used to index into a 1 6 
// entry table which specifies the way lo resolve the overlap. However, this 
// is highly redundant, as the table would actually respresents several rotated 
// and/or inverted instances of a few basic relationships: 
// 

// Horizontal 
// 

: ni| 

" • — • 



Vertical Diagonal Contained Crossing 

FT; "rf - rfti 

1-L - . 



// What we are really interested in determining is whether we "should" move 
// the rectangles horizontally or vertically to resolve the overlap, hence we 
// are testing for three states; Horizontal, Vertical and Don't Know. 

// . f 

// The macro gives us these three slates by XORing the high and low bits of 
// of the comparison lo reduce the table to 4 cases where 1 and 2 are 
// vertical and horizontal respectively, and then subtracting 1 so that the 
// 2 bit signifies "unknown- ness.'* 
// 

// Note that there arc some one-off cases in the comparisons because we arc 
// not actually looking at the third rectangle. However this greatly reduces 
// the complexity so these small errors are acceptible given the scale of the 
II rectangles we are comparing. 
// 

#definc INTERSECTON^\XIS(a, b) 

(((((a->len — b->left) « 1) | (a->top — b->top)) * \ 
(((a->right -- b->right) « 1) | (a->bottom « b->bottom))) - 1) 
^define 1NTE RS ECTlON_AX IS _ VERTICAL (0) 
#derlne INTERSECTtON_AXIS_HORIZONTAL (1 ) 

#defuie INTERSECnON_AXIS_UNKNOWN(code) (code & 2) 

If 

// 

// RemoveOvcrlap Q 
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APPENDIX A-continued 



// This is called from RemovcOverlaps to resolve conflicts when two 

// rectangles overlap. It returns the PMONITOR for the monitor is decided to 

// move. This routine always moves rectangles away from the origin so it can 

// be used to converge on a zero-overlap configuration. 

// 

// This function will bias slightly toward moving lprc2 (all other things 

// being equal). 

// 



LPRECT NEAR PASCAL RemoveOverlap (LPRECT Iprcl, LPRECT rprc2, LPRECT Iprcl) 
( 

LPRECT IprcMove, IprcStay; 

POINT ptCl, ptC2; 

BOOL fNegative; 

BOOLfClNeg; 

BOOL fC2Neg: 

int dCl, dC2; 

int XOffset; 

int yOffset; 

int nAxis; 

// 

// Compute the centers of both rectangles. We will need them later. 
// 

ptCl.x - RectCentcrX(lprcl); 
ptCl.y • RectCenterY(lprcl); 
ptCZx - RectCenterX(lprc2); 
ptc2,y - RectCenterY(lprc2); 

// 

// Decide whether we should move things horizontally or vertically. All 
// this goop is here so it will "feel" right when the system needs to 
// move a monitor on you. 

// 

nAxis - INTERSECTI ON_AXIS(lprcl, Iprcl); 
if (INTERSECTtON_AXIS_UNKNOWN(nAxis)) 

{ 

// 

// [s this a "big" intersection between two rectangles? 
// 

if (PtlnRectflprcl, ptel |J PtlnRectOprcI, ptC2)) 
{ 

// 

// This is a "big" overlap. Decide if the rectangles 
/; are aligned more "horizontal-ish" or "vertical-ish." 
// 

xOffect - ptCl.x - ptC2.x; 
if (xOffset < 0) 

xOffset -1; 
yOffset « ptCl.y - ptC2.y; 
if (yOffsct < 0) 

yOffset *- -1; 
if (xOffset >- yOffset) 

nAxis - INTERSECTION_AXlS_HORIZONTAL; 
else; 

nAxis - INTERSECnON__AXJS_ VERTICAL; 

} 

else 
{ 

// 

II This is a "small" overlap. Move the rectangles the 

II smallest distance that will fix the overlap. 

// 

if ((lprcI-> right - lprcl->left) <- (lprcI->bottom - lprcI->top)) 

nAxis - INTERSECT10N_AXIS_HORIZONTAL; 
else; 

nAxis - I NTERSECTtON_AXIS_ VERTICAL; 

} 

} 
// 

// We now need to pick the rectangle to move. Move the one 
// that is further from the origin along the axis of motion. 
// 

if (nAxis « INTERS ECT10N_AXIS_HORI20NTAL) 
{ 

dCl - ptCl.x; 
dC2 - ptCZx; 

} 

else 
{ 

dCl - ptcl.y; 
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APPENDIX A-continued 



dC2 - ptC2,y, 

} 

if ((fClNeg - (dCl < 0)) !- 0) 

da -1; 
if ((fC2Neg - (dC2 < 0)) !- 0) 

dC2 -1; 
if (dC2 < dO) 
{ 

IprcMove - lprcl; 
IprcStay « rprc2; 
fNcgativc - fClNeg; 

} 

else 
{ 

IprcMove - Iprc2; 
IprcStay - rprcl; 
fNegalive - fClNeg; 

} 

// Compute a new home for the rectangle and put it there. 

// 

if (aAxis - I NTERSECTION_AXIS_HOR IZONTAL) 
{ 

int xPos; 

if (fNegalive) 

xPos - lprcStay->left - (IprcMove- aright - lpicMove->left); 
else 

xPos » IprcStay- > right; 
xOffset - xPos-lprcMovc->left 
yOffset - 0; 

} 

else 
{ 

int yPos; 

if (fNegalive) 

yPos - IprcStay- >top - (IprcMove- >boltom - !prcMove->top); 
else 

yPos «» IprcStay- >bottom; 
yOffsei ■ yPos - IprcMove- >top; 
xOffset - 0; 

} 

OffsetRect( IprcMove, xOffset, yOSset): 

return IprcMove; 

} 



What is claimed is: 

1. A method, performed by a computer system, of arrang- 
ing monitors in logical space, the method comprising: 

determining relative positions in logical space for a plu- 
rality of monitor spaces; 

comparing the relative positions of the monitor spaces; 
and 

positioning the monitor spaces in logical space based on 
a result of the comparing to form a contiguous and 
non-overlapping region. 

2. The method of claim 1 wherein the determining, 
comparing and positioning are performed upon initialization 
of the computer system. 

3. The method of claim 1 wherein the determining, 
comparing and positioning are performed automatically in 
response to a geometry change for one or more of the 
monitor spaces. 

4. The method of claim 3 wherein the geometry change 
comprises adding a monitor space to the computer system. 

5. The method of claim 3 wherein the geometry change 
comprises removing a monitor space from the computer 
system. 

6. The method of claim 3 wherein the geometry change 
comprises changing a characteristic of a monitor space. 

7. The method of claim 6 wherein the changed monitor 
space characteristic comprises a resolution parameter. 

8. The method of claim 1 wherein the comparing com- 
prises iteratively comparing the position of each monitor 
space against every other monitor space. 



9. The method of claim 1 wherein the comparing com- 
prises determining whether any two monitor spaces overlap 
one another. 

10. The method of claim 1 wherein the comparing com- 
prises determining whether gaps exist between the monitor 

4 5 spaces. 

11. The method of claim 1 wherein the positioning 
comprises placing a monitor space at a constrained location 
in logical space. 

12. The method of claim 11 further comprising choosing 
50 the constrained location such that it enhances efficiency in an 

operating system of the computer system. 

13. The method of claim U wherein the constrained 
location comprises a boundary aligned at a predetermined 
number of units in logical space. 

55 14. The method of claim 1 wherein the positioning 
comprises moving the monitor spaces inward in logical 
space to remove gaps between monitor spaces. 

15. The method of claim 1 wherein the positioning 
comprises moving the monitor spaces outward in logical 
space until no monitor space overlaps any other monitor 

60 space. 

16. The method of claim 15 wherein the positioning 
further comprises moving the monitor spaces inward in 
logical space to remove gaps between monitor spaces. 

17. The method of claim 1 wherein the comparing com- 
65 prises comparing the respective positions of two monitor 

spaces relative to a predetermined location, and the posi- 
tioning comprises moving one of the two monitor spaces 



10/03/2002, EAST Version: 1.03.0002 



5,9: 

23 

based on a relationship between the predetermined location 
and the position of the monitor space to be moved. 

18. The method of claim 17 wherein the predetermined 
location comprises a center of a virtual desktop. 

19. The method of claim 17 wherein the one of the two 
monitor spaces that has a center point farther from the 
predetermined location is moved. 

20. The method of claim 19 wherein the monitor space is 
moved outward in logical space. 

21. The method of claim 1 wherein the comparing com- 
prises determining whether a horizontal overlap exists 
between two monitor spaces. 

22. The method of claim 1 wherein the comparing com- 
prises determining whether a vertical overlap exists between 
two monitor spaces. 

23. The method of claim 1 wherein the comparing com- 
prises determining whether one monitor space contains the 
center of another monitor space. 

24. The method of claim 1 wherein the comparing com- 
prises determining whether two monitor spaces are closer to 
being horizontally aligned or closer to being vertically 
aligned. 

25. A method, performed on a computer system, of 
managing the display of a graphic object positioned within 
a logical display space that comprises a plurality of monitor 
spaces, the method comprising: 

sensing a geometry change within the display space; 

recording a position for each of the monitor spaces that 
forms the logical display space; and 

manipulating the graphic object in response to the geom- 
etry change. 

26. The method of claim 25 wherein the recording com- 
prises saving coordinate values in a data structure. 

27. The method of claim 25 wherein the geometry change 
comprises an addition or a removal of a monitor space. 

28. The method of claim 25 wherein the geometry change 
comprises a change in a monitor space characteristic. 

29. The method of claim 25 wherein the geometry change 
comprises a change in position in logical space of a monitor 
space. 

30. The method of claim 25 wherein the geometry change 
comprises a change of shape in the display space. 

31. The method of claim 25 wherein the geometry change 
comprises a change of orientation of the display space. 

32. The method of claim 31 wherein the manipulating 
comprises moving the graphic object in logical space to 
compensate for the change in orientation of the display 
space. 

33. The method of claim 25 wherein the logical display 
space comprises a contiguous, non-overlapping virtual desk- 
top. 

34. The method of claim 25 wherein the manipulating 
comprises moving the graphic object in logical space. 

35. The method of claim 34 wherein the moving com- 
prises repositioning the graphic object in logical space 
relative to the display space. 

36. The method of claim 25 wherein the manipulating 
comprises moving the graphic object in logical space such 
that the graphic object remains in a same location relative to 
a monitor space. 

37. The method of claim 25 wherein the geometry change 
comprises a removal of a monitor space and the manipulat- 
ing comprises moving the graphic object to a different 
monitor space. 
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38. A computer program, residing on a computer readable 
medium, for arranging a plurality of monitor spaces in 
logical space, the computer program comprising instructions 
to: 

(a) select a monitor space from among the plurality of 
monitor spaces; 

(b) compare a position in logical space of the monitor 
space selected in (a) with another monitor space; 

> (c) move one of the two chosen monitor spaces based on 
a result of (b); 

(d) repeat (b) and (c) until the monitor space selected in 
(a) does not overlap any other monitor space; and 

(e) repeat (a), (b). (c) and (d) until no monitor space 
as overlaps any other monitor space. 

39. The computer program of claim 38 wherein one of the 
two monitor spaces is moved in (c) if the comparison in (b) 
determines that an overlap exists between the monitor 
spaces. 

20 40. The computer program of claim 38 wherein one of the 
two monitor spaces is moved outward in logical space in (c). 

41. The computer program of claim 38 wherein one of the 
two monitor spaces that has a center point farther from a 
predetermined location is moved outward in logical space in 

25 ( C >- 

42. The computer program of claim 38 further comprising 
instructions to: 

(f) select a monitor space from among the plurality of 
monitor spaces; 

30 (g) designate the chosen monitor space as belonging to a 
known group and the unchosen monitor space or spaces 
as belonging to a unknown group; 

(h) select a monitor space from the unknown group based 
on a relationship between the selected monitor space 

35 and the known group; 

(i) move the monitor space selected in (h) in logical space; 
(j) designate the monitor space selected in (h) as belong- 
ing to the known group; and 

40 (k) repeat (h), (i) and (j) until the monitor spaces form a 
contiguous region. 

43. The computer program of claim 42 wherein (h) 
comprises instructions to deselect a monitor space if it 
would overlap any other monitor space in the unknown 
group upon being moved. 

44. The computer program of claim 42 wherein a monitor 
space closest to a predetermined location is selected in (Q- 

45. The computer program of claim 44 wherein the 
predetermined location comprises a center of a virtual 
desktop. 

50 46. The computer program of claim 42 wherein (i) com- 
prises instructions to move the monitor space selected in (h) 
to a position in logical space at which that monitor space is 
contiguous with a monitor space in the known group. 

47. The computer program of claim 42 wherein the 
55 monitor space is moved horizontally or vertically in (i). 

48. The computer program of claim 42 wherein succes- 
sive iterations of (i) cause the monitor spaces to move 
towards each other. 

***** 



10/03/2002, EAST Version: 1.03.0002 



